In channel-manager.ts, openai-responses is added as a fall-through to the existing openai test path (testChannel and testChannelDirect), but that test function almost probes the /chat/completions endpoint — not /responses. This means a valid openai-responses channel could fail its connectivity test, while a misconfigured one might pass if the base URL happens to serve Chat Completions. A dedicated test path (or at minimum passing the resolved endpoint URL into the shared test helper) would be more correct here.

In ChannelForm.tsx, PROVIDER_CHAT_PATHS['openai-responses'] is set to '/responses' (no /v1 prefix), which is consistent with how openai: '/chat/completions' works given that the default base URL already includes /v1. However, if a user sets a custom base URL that doesn't include /v1, they'll silently get the wrong path — worth a comment clarifying the assumption, or a validation note in the UI.

The new ResponsesAdapter type definitions look thorough — modeling ResponsesFunctionCallItem and ResponsesFunctionCallOutputItem as distinct input item types rather than overloading the role-based message structure is the right call for this API's format. It would be worth verifying that the id field on ResponsesFunctionCallItem (marked optional) is correctly round-tripped when the API returns it, since omitting it on continuation requests could cause the API to treat it as a new call rather than a resumption.